SQL レベルのメトリクス をサポートしたパフォーマンスインサイトで高負荷状態のDB稼働を確認してみた

AWSチームのすずきです。

SQL レベルのメトリクス をサポートを開始したパフォーマンスインサイト(Performance Insights)を利用して、 高負荷状態に陥った Amazon Aurora Provisioned (MySQL5.6互換) の稼働状況を確認する機会がありましたので紹介させていただきます。

環境

過負荷が発生した環境は、 CMS(WordPress)の 記事データベースとして利用している Aurora でした。

Performance Insights

SQL情報

SQLの情報として、下記項目が表示されるようになりました。

• calls/sec : 毎秒ごとの呼び出し
• avg latency (ms)/call : 平均レイテンシー
• rows examined/call : 一度の呼び出しで返される行数

一回の処理時間は短いが実行回数が多く、チリも積もって高い負荷が積み上がった状況について、より把握しやすくなりました。

従来の表示 (3月頃)

期間指定

表示期間は 最短1分、1秒の粒度で負荷を確認する事が可能です。

1週間

半日

1時間

1分

CloudWatch

DB負荷がごく短時間で収束した場合や、標準で7日以上過去のデータを確認する必要がある場合、 CloudWatchのメトリック「DBLoad」 で確認する事が可能です。

高負荷を捉える場合、「最大値」、「P99」の統計値の利用が便利です。

SQLの確認

任意のSQLを指定し、実効詳細を確認する事が可能です。

「スニペットのコピー」「SQLのダウンロード」で取得したSQLを利用して、実行内容や実行計画(EXPLAIN)を確認、非効率なSQLについては改善を検討します。

高負荷や、更新処理が発生する場合には、クローンやスナップショットからのリストアなどで非本番環境の利用をおすすめします。

スライス基準

スライス基準を切り換える事で、ボトルネックの原因、発生原因がわかる場合があります。

待機

今回の負荷原因は、IOの性能限界。IOの発生を抑制する事で負荷耐性の向上が期待できます。

ホスト、ユーザ

今回は均等な負荷分散が実現されていましたが、特定の環境、バッチや管理用サーバなどが負荷発生源であった場合の特定に役立ちます。

負荷の原因について

10並列程度で実行されていたクローラーが今回の負荷の発生原因でした。

AWS WAFのレートルール、AWS 提供のマネージドルール、匿名IPリストなどの対策は実施していましたが、 異なるIPからのアクセス、UserAgentも偽装されていたため、Auroraの性能限界を大きく超えるDB負荷が発生していました。

AWS マネージドルールの匿名 IP リストが AWS WAF に追加

対策

接続元のIPアドレスが国外、通常のブログ閲覧者への影響が無い事を確認した上で、 AWS WAF を利用して、「/24」の範囲でIP制限を実施する暫定措置を実施しました。

恒久対策として、SQL処理周りの最適化を施したアプリ改修と、 自動スペックアップや、DBの強制再起動が期待できる AuroraServeless についても リリースの前倒しを予定しています。

まとめ

Performance Insights、データベースの負荷状況を可視化し、ボトルネックの特定に役立つ情報を素早く確認する事が可能です。

今回紹介したAurora (MySQL56互換)以外でも、実行条件を満たす DBエンジン、インスタンスタイプであれば、 多くのRDS環境で Performance Insights を利用する事が可能です。

データ保持期間、デフォルトの7日間であれば Performance Insights は 追加費用なく利用できますので、ぜひご活用ください。

• Amazon RDSパフォーマンスインサイトの使用